Most users on the internet today are concerned about privacy and security when sending personal email or conducting banking transaction. The internet has responded with HTTPS. Many websites that are used to transmit sensitive data across the internet are protected by encryption. Webmail, banking, and mobile applications such as WhatsApp, Instagram, and Twitter are mostly encrypted in order to protect our sensitive information. However, few are aware of this encryption and understand its mechanisms or its exploitation by criminal entities. In this paper, we introduce the mechanics of HTTPS and how Law Enforcement Agencies can bypass the security in order to conduct cyber investigations.
A Brief introduction to TCP/IP
The internet today operates by a set of rules, or protocols, that is agreed upon by nearly every connected device. These rules dictate the method in which data that is to be communicated between two devices is sent and received. One of these protocols, Internet Protocol (IP), establishes the rules for breaking the data being sent across the internet into smaller packets, and for the method in which the packets are labeled with the sender’s and receiver’s address. Another protocol, Transmission Control Protocol (TCP), establishes the rules for handling sequencing errors, lost data, and reassembly of the data packets.
Each TCP/IP packet contains information for transport, but also contains the information being sent, also known as the payload. For example, if a Facebook user posts “Hello everyone” to his or her wall, this data is cut into small pieces to simplify transmission. Each piece of data has additional transport and reassembly information pieces attached to it and called a packet. When each packet is in transit, the packet’s addressing information is used to get the packet to the correct place. Once each packet has arrived at the destination, the reassembly information is used to connect the payload of each packet until “Hello everyone” is posted on the user’s wall.
While in transit, the packets can be intercepted by various methods. If the data is not encrypted, the entire message can be reconstructed and read. If the user is attempting to transmit and receive sensitive information, such as email or bank information, the servers providing the content should allow for the use of cryptographic protocols to encrypt the data during the transmission. The common cryptographic protocols on the internet are Transport Layer Security (TLS), and the protocol TLS replaced, Secured Sockets Layer (SSL). These cryptographic protocols use two keys to encrypt the transmitted data and validate the connection to the content service. This method prevents placing a device in between the connection and reading the content of the data.
In order to begin a transmission that is encrypted, the user’s computer (client) initiates a handshake with the server from which the computer will receive content. During this handshake, the client will send the SSL version, SSL settings, and other information to the content server. The content server will then return the handshake and along with its digital certificate information. The client can authenticate the certificate information by comparing with a trusted root certificate database that was pre-installed in the client, or by connecting with the Certificate Authority (CA) to verify the certificate information. An encryption key that is available in the digital certificate installed in the client will be used to encrypt the private key information generated by the client. When the public key and private key are conjoined, they are called the master secret and it is used to encrypt all subsequent data.
Figure 1 - The HTTPS Connection process
Figure 1 shows the HTTPS connection process. The first step in the connection process is the SSL handshake from the client. This is identified as ClientHello. The server responds with its handshake message, ServerHello. Then the server sends its certificate information, along with its public key. After this information is sent, the server will tell the client that it has finished sending the initiation information by sending the ServerHelloDone message. Once the client verifies the certificate information by comparing it to its own certificate database or connecting with the Certificate Authority, the client will generate a private key, the pre-master secret from a combination of the server’s public key and the client’s generated private key. The client will send this information to the server in the ClientKeyExchange message. When the server receives the pre-master secret, it will generate a master secret from the information and send it to the client in the ChangeCipherSpec message. Once sent, a Finish message will be sent to the client to inform the client that all communication will be encrypted.
The Digital Certificate
A critical component of SSL/TLS encryption is the digital certificate. The digital certificate is created and issued by a trusted 3rd party, called a Certificate Authority (CA), after the server for which a party requesting a certificate has been verified. This certificate is installed into the content server and used to verify its authenticity to the client accessing the server’s content. Most devices come pre-installed with a database of trusted certificates. The client will compare the content server’s certificate to the client’s database, and if the certificate can be matched with a trusted certificate in the client’s database, the content is accessed with no notifications. If no match can be found, the client sends a warning message to the user that the certificate is not valid and asking whether or not the user would like to proceed with the session. This certificate system is in place to ensure sensitive information is exchanged only with a trusted server and to prevent unauthorized access to sensitive information and the encryption keys by a device within the line of communication.
It is possible to view the certificate database on the client by going to the Internet Options window and clicking the “Content” tab. Under the Certificates section, click the “Certificates” button. This will open the Certificates window. In the certificates window, click the “Trusted Root Certificates” tab. A list of the trusted root certificates database will now be displayed (Figure 2). This list and the other tabs contain the list of certificates against which the client will verify the authenticity of the certificate it had received from the content server. If the client cannot find the certificate, it may connect with the Certificate Authority for authentication. If the certificate cannot be verified, then a warning message is sent to the user asking for permission to accept the certificate.
Figure 2 - Trusted Root Certificate database
On an encrypted website, a lock will be visible in the browser’s address bar. The address will also be preceded by HTTPS:// instead of the non-encrypted HTTP://. To learn more about the content server’s certificate, you can right-click the lock to view the website’s security and privacy information (Figure 3). Click on the “Connection” tab to view more information about the content server’s certificate. Here you will find the verification information and can follow the Certificate Information link to learn more about the source of the certificate.
HTTPS is powerful method to protect the transmission of sensitive information over the internet. That is why content service provides such as Facebook, Gmail, Yahoo, Hotmail, banks, and many other entities whose business relies on the safety and privacy of their customers. And now, with mobile devices becoming the primary source of internet access, the use of HTTPS is now prevalent with mobile applications. This is great for users whose intentions are the innocent use of the internet. However, there are users that exploit the internet to conduct criminal behavior that is dangerous for individuals and societies, and HTTPS becomes a barrier that makes investigating malicious behavior on the internet difficult for law enforcement agencies.
The Decision Group HTTPS Interceptor solution
Because of the strong encryption of the HTTPS system, it is virtually impossible to crack. That is why it is critical to capture the key exchange between the client and content server. With the key, any encryption between the client and the content server can be decrypted. However, because of the certificate system, placing a device in the line of communication will alert a user to the mismatch in certificates. Decision Group’s HTTPS Interceptor can use three methods to intercept the master key exchange undetected and allow investigators to view the decrypted messages in the exchange.
Method 1:
A Trusted Root Certificate can be obtained from a government agency, from the company whose content server is being accessed, or from the CA. When used in conjunction with the Man in the Middle (MITM) attack, a client will access the internet through the HTTPS Interceptor. With a Trusted Root Certificate in the HTTPS Interceptor, the client will find a match with its own certificate database and the session will proceed as normal. This will allow the key exchange to be intercepted and the key used to decrypt all subsequent encrypted messages.
Method 2:
A certificate can be created and signed by the certificate authority. Once this certificate is signed, a Content Service Provider can be compelled to inject the certificate into the data stream to ensure that the client will trust the certificate. This will allow the MITM to proceed with the session as normal.
Method 3:
A fake certificate can be created and loaded into the target computer’s certificate database. This method will allow normal access to HTTPS website, but it requires physical access to the target computer.
SSL/TLS provides a powerful cryptographic tool for protecting sensitive information transmitted over the internet that, like all tools, can be exploited for malicious purposes. Decision Group’s goal is to provide Law Enforcement Agencies the tools and training they need to protect citizens from criminals and provide a safe and secure society.
|
